1. Field of the Invention
The present invention relates to computer systems with novel input-output (I/O) architectures, and more particularly, and not by way of limitation, to systems for hiding peripheral devices connected to a bus from the host operating system and associated host processor.
2. Description of Related Art
A conventional computer system typically includes one or more central processing units (CPUs) capable of executing algorithms and one or more memory subsystems. Computer systems also include peripheral devices, or, peripherals, for inputting and outputting data. Some common peripheral devices include, for example, monitors, keyboards, printers, modems, hard disk drives, floppy disk drives, and network controllers. As known in the art, peripheral devices may be conveniently categorized into several classes based on their functionality. For example, the "block storage device" class of peripherals may include hard disk drives, whereas the "Local Area Network (LAN) ports" class may include LAN controllers, such as, for example, Ethernet controllers. The various components of a computer system communicate and transfer data using a bus system which is connected to the communicating components.
One of the key factors in the performance of a computer system is the speed at which the CPU operates. Generally, the faster the CPU operates, the faster the computer system can complete a designated task. Another method of increasing the speed of a computer system is using multiple CPUs, commonly known as multi-processing. With multiple CPUs, algorithms required to complete a task can be executed substantially in parallel as opposed to their sequential execution.
However, the addition of a faster CPU or additional CPUs can result in different increases in performance among different computer systems. Although it is the CPU that executes the algorithms required for performing a designated task, in many cases, it is the peripherals that are responsible for providing data to the CPU and storing or outputting the processed data from the CPU. When a CPU in operation attempts to read or write to a peripheral, the CPU often "sets aside" the algorithm which it is currently executing and is diverted to executing the read/write transaction (also referred to as an Input/Output transaction, or an I/O transaction) for the peripheral. As can be appreciated by those skilled in the art, the length of time that the CPU is diverted is typically dependent on the efficiency of the I/O transaction.
Although a faster CPU may accelerate the execution of an algorithm, a slow or inefficient I/O transaction process associated therewith would create a bottleneck in the overall performance of the computer system. As the CPU becomes faster, the amount of time executing algorithms becomes less of a limiting factor compared to the time expended in performing an I/O transaction. Accordingly, the improvement in the performance of the computer system that could theoretically result from the use of a faster CPU or the addition of another CPU may become substantially curtailed by the bottleneck created by I/O transactions. Moreover, it can be readily appreciated that any performance degradation due to such I/O bottlenecks in a single computer system may have a stifling effect on the overall performance of a computer network in which the computer system is disposed.
Operating peripheral devices in association with a computer system typically requires a piece of executable code, known commonly as a device driver. Because peripherals are often manufactured separately from the CPU, the operation of a peripheral is generally effectuated by a unique device driver associated with the specific peripheral. The device driver, which controls the peripheral, is an executable computer program that is executed by the CPU and must be compatible with the particular operating system (OS) of the computer system. It can be readily seen that because device drivers are unique to both operating systems as well as peripherals, a considerable number of device drivers are typically required to support the numerous possible combinations of peripherals and operating systems. Accordingly, it can be appreciated that the ensuing device driver proliferation thwarts the objective of device driver portability in the design of cross-platform computer system architectures.
Based on the foregoing discussion, it should be appreciated that current computer systems with a conventional I/O architecture utilizing device drivers described above suffer from a lack of device driver portability and performance constraints due to I/O bottlenecks. In order to address these shortcomings, an alternative I/O architecture--commonly known as the Intelligent Input/Output (I.sub.2 O) architecture--has been developed in the computer industry. Because the teachings of the present invention may be better described in relation to the I.sub.2 O architecture, a brief description thereof is provided hereinbelow.
The I.sub.2 O architecture uses a "split driver" model which inserts a messaging layer between the portion of the device driver specific to the operating system and the portion of the device driver specific to the peripheral. The messaging layer splits the single device driver of today into two separate modules--an Operating System Service Module (OSM) and a Downloadable Driver Module (DDM). The only interaction one module has with another module is through this messaging layer which provides the communication means.
The OSM comprises the portion of the device driver that is specific to the operating system. The OSM interfaces with the operating system of the computer system (which may also be referred to in the art as the "host operating system") and is executed by the host CPU or processor. Typically, single OSM may be used to service a specific class of peripherals. For example, one OSM would be used to service all block storage devices, such as hard disk drives and CD-ROM drives.
The DDM provides the peripheral-specific portion of the device driver that understands how to interface to the particular peripheral hardware. To execute the DDM, an I.sub.2 O Input/Output Processor (IOP) is added to the computer system. A single IOP may be associated with multiple peripherals, each controlled by a particular DDM, and contains its own operating system such as, for example, the I.sub.2 O Real-Time Operating System (iRTOS). The DDM directly controls the peripheral, and is executed by the IOP under the management of the iRTOS.
Those skilled in the art will recognize that a DDM may typically comprise a Hardware Device Module (HDM) that directly interfaces with the peripheral and is responsible for its control and data transfer associated therewith. DDMs can also comprise an Intermediate Service Module (ISM) which is an additional software interface to the HDM. The ISM is often used for filtering, encoding, and decoding messages to the HDM.
In general operation, the communication model used in the I.sub.2 O architecture is a message passing system. When the CPU seeks to read or write to a peripheral in an I.sub.2 O system, the host operating system makes what is known as a "request". The OSM translates the request by the host operating system and, in turn, generates a message. The OSM sends the message across the messaging layer to the DDM associated with the peripheral which processes it appropriately to achieve a result. Upon completion of the processing, the DDM sends the result back to the OSM by sending an appropriate message through the messaging layer. It can be appreciated that to the host operating system, the OSM appears just like any other device driver.
By executing the DDM on the IOP, the time-consuming portion of transferring information from and to the peripheral hardware is off-loaded from the CPU to the IOP. With this off-loading, the CPU is no longer diverted for inordinate amounts of time during an I/O transaction. Moreover, because the IOP is a hardware component essentially dedicated to the processing of the I/O transactions, the problem of I/O bottlenecks is mitigated.
The I.sub.2 O architecture also significantly reduces the number of device drivers written on the basis of the split driver model. Typically, peripheral device manufacturers need only write a single DDM for a particular peripheral which can now operate with any host operating system. The vendors of the host operating system need only write one OSM for each class of peripherals, e.g., the network controller class.
One of the goals of the I.sub.2 O architecture is to allow standard "non-intelligent" or "semi-intelligent" peripheral devices to be controlled by a generic I.sub.2 O IOP resource that could be added to a computing system. If the IOP contains the necessary software to control a particular peripheral device, the device may be abstracted through the IOP to "look" like an intelligent 120 peripheral. However, it may be appreciated that in order to incorporate the I.sub.2 O technology in a computer system and realize the benefits afforded thereby, host processors and operating systems need to be able to differentiate between peripheral devices that are under the control of an IOP (that is, peripherals subordinate to the IOP) and peripheral devices that are not (that is, "system" or "public" peripherals under the control of the host processor/s). Although system software that is I.sub.2 O-compliant is typically capable of making this distinction, legacy software, i.e., software developed and deployed prior to the development of the I.sub.2 O architecture or which is otherwise not I.sub.2 O-compliant, on the other hand, usually cannot make this distinction. Therefore, to retain the investment made in the legacy software through its continued use while at the same time realizing the benefits of the I.sub.2 O technology, there has arisen a substantial need for schemes whereby subordinate peripheral devices are rendered "invisible" or "hidden" from host processors and operating systems.
One of the current methods used for hiding peripheral devices involves the use of an IOP having bus-to-bus bridge functionality. Typically, the bridge functionality of the device is used for coupling two buses, such as the Peripheral Component Interconnect (PCI) buses. The up-stream bus may be referred to as a primary bus, whereas, the down-stream bus may be referred to as a secondary bus. The IOP (for example, the i960.RTM. processor), provided for controlling the peripherals on the secondary bus, uses its private address space allocation mechanism for hiding such devices. Accordingly, devices under the control of the IOP are hidden from the host processors and their related software by placing these devices behind the PCI-to-PCI bridge and allocating memory address space to the down-stream PCI bus for address information pertaining to them. The allocated memory address space is inaccessible by the host processors and, thus, the peripheral devices are rendered invisible thereto.
Another known method of hiding peripheral devices involves the use of certain switching devices (for example, components known in the industry as QuickSwitch.RTM. devices) for blocking a PCI signal line that is used as "chip select" signal for the peripheral devices during their configuration. When a host processor runs configuration cycles to these devices, because of the blocking of the appropriate PCI signal line, they will not be enumerated.
Current solutions, such as those described hereinabove, for hiding peripheral devices from host processors have various deficiencies and shortcomings. For example, one approach requires the use of a particular type of IOP (having a PCI-to-PCI bridge) with its private address space allocation mechanism. Also, in this approach, it is required that the devices be placed down-stream from the PCI--PCI bridge for hiding them. The "quick switch" approach, on the other hand, entails the use of additional components, thereby adding to the cost and complexity of the computer system.